home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3469 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.5 KB
  1. Path: hydra.zrz.TU-Berlin.DE!rawneiha
  2. From: rawneiha@hydra.zrz.TU-Berlin.DE (Philipp Boerker)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: TMapping again!
  5. Date: 20 Feb 1996 15:43:24 GMT
  6. Organization: Technical University Berlin, Germany
  7. Message-ID: <4gcq6s$b1h@brachio.zrz.TU-Berlin.DE>
  8. References: <38232371@kone.fipnet.fi> <4fntd3$g56@sunsystem5.informatik.tu-muenchen.de> <38232442@kone.fipnet.fi> <4fvnjb$gdm@oreig.uji.es> <4g147q$sit@maureen.teleport.com> <4ga6lr$rp8@brachio.zrz.TU-Berlin.DE> <4gc5ur$brr@maureen.teleport.com>
  9. NNTP-Posting-Host: hydra.zrz.tu-berlin.de
  10.  
  11. >: > I would unroll the innerloop, you probably can save hundreds of dbra
  12.  
  13. >: If you have an object with let's say 5000 polys umrolling will mean
  14. >: a big overhead because of the treatment of "pixels modulo unrolling".
  15. >: You may never enter that unrolled loop!
  16.  
  17. > What do you mean by "pixel modulo unrolling"? Never enter the loop?!?!
  18. > then you dont draw any pixels so its VERY fast :)
  19.  
  20. if you do a innerloop mapping 16 pixels at once you need to map   
  21. number_of_pixels_you_have_to_map % 16 independently. For instants
  22. 45 pixels to map would result in 2 executions of your 16 pixel loop
  23. plus 13 executions of 1-pixel loop. number_pixel < 16 will not make use
  24. of your loop at all!
  25.  
  26. > Its true that there is some overhead, But here is an example:
  27.  
  28. >    ...
  29. >    moveq    #%1111,d3    ;2
  30. >    and.w    d2,d3        ;2
  31. >    neg.w    d3        ;2
  32. >    lsr.w    #4,d2        ;4
  33. >    jmp    (.z,pc,d3.w*8)    ;10 = 20 per scanline
  34. > ..    REPEAT    16
  35.   ^^ what a great label :)
  36.  
  37. >    move.b    (a0,d0.w),(a1)
  38. >    addx.l    d1,d0
  39. >    adda.l    a2,a1
  40. >    ENDR
  41. >.z    dbra    d2,..        ;6 per pixel
  42. >    ...
  43.  
  44. Hm, this is a wall mapping loop, I thought we were talking about
  45. polygon mapping, where you have lots of polys smaller than 16 pixels width
  46. if you do *many* polys (therefor the number 5000).
  47.  
  48. > now if this 'polygon' is more then 4 pixel height its worth it... well,
  49. > if its a few pixel width too :) 
  50.  
  51. ??? to use this loop you will have to have more than 16 pixels!
  52. The treatment of number_pixels mod 16 will add a big overhead for small
  53. polys, like I said above.
  54.  
  55.  
  56. > If the poly where to be ~4x4 pixel I would think rendering then using
  57. > the average color of the texture (precalculated of course) and use a
  58. > flat shading function (using also the average of the light value at the
  59. > triangle vertices
  60.  
  61. You will hardly stuff all that into your 256 B cache. According to my
  62. experience it is better to have an ordinary loop and outer loops in cache
  63. than spending the cache for case-optimized loops.
  64.  
  65. Greets,
  66. Phil.
  67. grond/matrix
  68.  
  69.